mac miniをNASとして使う計画
コスト効率プラン
編集作業はSSDで行う
メディアサーバーはmac mini
コスト：24万円ぐらい。半額！
mac mini 11万円(base model + 10GbE)
enclosure
ストレージ
アーカイブ用HDD 12TB 4.6万円
46460/12
HDDの価格は2021年の時よりだいぶ値上がりしてるな... アーカイブ用SSD ありもの（4TB）
Time Machine用 ありもの
作業用SSD + エンクロージャ 3.5万円
QSirchは使えなくなるので書籍の内容検索はGoogleにお任せ
浪漫はないけど他人に勧めるならこっちだな
Backblazeがちゃんとバックアップとして機能するのかだけが問題
行動シナリオ
コンテンツ消費
PCからmac miniにアクセスして動画再生
写真はMac miniに繋いで確認
写真データを利用したい際には
編集用SSDをMac miniに接続
Mac miniからエクスポート
編集用SSDを作業用PCに接続して使う
Mac miniのメディアサーバー上からiPadでの動画視聴
SMB経由でinfuseで見てる
plex media serverなどもあるらしい
iPadで書類が見たい時にはGoogle Driveに接続
動画編集・制作
保守的な方法
動画編集用のSSDを繋いで動画編集
ひと段落したデータはMac miniにSSDを接続してのHDDに保存
攻めた方法
PC - (10GbE) - mac mini - (thunderbolt4) - SSD
o3.iconThunderbolt 3/4 の外付けSSDは理論 22 Gbps-32 Gbps（≒2.7-4 GB/s）で動く
10 GbE の SMB 転送は上限 1 GB/s 弱。したがってネット共有時は回線がボトルネックで、SSD側は常に余裕がある。単独ユーザーの編集やビルド用途なら体感は NAS と遜色ない。
o3.icon
Mac mini ↔ CalDigit TS4 の2.5 GbE (2.5 Gbps ≒310 MB/s 実効250〜280 MB/s) ←ここが最も遅い
ネットワーク ↔ Windows 5 GbE (5 Gbps ≒620 MB/s 実効550 MB/s)
SSD → Thunderbolt4 (40 Gbps ≒5 GB/s)
実際には2-3GB/sぐらいしか出ない基素.icon
4K ProRes 422 HQ 1ストリーム(約94 MB/s)なら余裕、複数ストリームや巨大コピーでは待ち時間が出る
o3.iconNAP QNA-UC5G1T は macOS Catalina までしか公式ドライバがなく、Apple Silicon＋Ventura/ Sonoma では 1 GbE でしか認識しない・まったく認識しない報告が多い。うまく動かなければボトルネック改善どころか低下する。
マ？基素.icon
QNAP has ended official support for MacOS and Linux since 2021/01. Users can download the Marvell® AQtion AQC111U driver from Marvell®’s official website. Click here to download the driver.
10 GbEが出せる上限
理論 10 Gb/s ÷ 8 = 1.25 GB/s
ヘッダ／SMBプロトコル損失 約10〜15 %
→ iperf3で9.9 Gb/s、SMB単発コピーで1.0〜1.1 GB/s前後が現実値 内蔵／外付けNVMe（Thunderbolt 40 Gb/s） 2.5〜3 GB/s
SATA SSD 0.5〜0.6 GB/s
バックアップ
Mac miniのHDDからbackblazeでバックアップ
iPhoneで撮った写真はmac miniに繋いで写真AppでSSDにバックアップ
情報検索
Google Drive頼り
物理構成
Mac mini
アーカイブ用HDD：すべてのデータアーカイブ。backblazeでバックアップしている。大容量。
アーカイブ用SSD：プライベートの写真・動画用。backblazeでバックアップしている
SSDでないと写真の読み出しが遅すぎてストレスになる
Time Machine用HDD：Time machine用。バックアップはなし
作業用SSD
一時的な作業用のSSD。この中のデータはバックアップされない
主として動画編集に使う
（動画バックアップ用HDD）
Google Drive：書類全て
マスターデータをクラウドストレージに置く恐怖はある
欠点
RAIDで冗長化していないので1発で故障する=故障時のダウンタイムが大きい
Backblazeがサービスを終了すると、S3 Glacier Deep Archive等にバックアップするスクリプトを自作する必要がある
融通が効かないのでやりたくない。この辺りはNASならHBS 3の恩恵がある 作業用の接続が面倒
PDFの中身検索がGoogle Driveに依存する（Qsirchの方がよく作り込まれている）
ストレージの特性を駆使した利用ができなくなる
ストレージのチェックを手動でやる必要がある
どうせ忘れてやらなくなる=障害性が上がる
バックアップの検証が必要
TR-004のRAIDを消去した後にバックアップできるのか？ 実際のバックアップイメージ
ツリー表示の画面で選んでいくのですが、ここが重くて、自分の場合は画面を開いてから中身が表示されるまで1分ほどかかります（ファイル数によるかも）。分割DLのためにこの画面は何度も来ることになるので、そこそこだるいです。
複数のリストアファイルを同じフォルダに解凍できないようなので、個別にフォルダを作って解凍してやる必要があります。これもちょっと面倒。
解凍したファイルはドライブ直下からのフォルダ構造が維持されているので、エクスプローラ上でドラッグ＆ドロップしてやるだけでマージできます。これで元の状態に復元完了です。
僕の場合は2TBちょっとのファイルで、効率よくやっても数日はかかるなという感じでした（執筆時点でまだ途中）。
Dropboxに使いづらいって言われてるのウケる
o3.icon実務アドバイス
基素.icon私の運用の考慮に見落としはないだろうか？
o3.icon
考え漏れになりやすいポイントを、ざっと洗い出しました。すでにメモに入っている話題は省き、触れていなかった／深掘り不足と思われる所だけ挙げています。
長期運用コストと部品寿命
SSD寿命（TBW）。動画編集で書き込みが多いと 3～5 年で全交換が必要になる場合も。予備費を計上しておくと安心。
冷却ファンや電源の交換時期。NASもMac miniもどちらも3～5 年でファンが劣化しがち。
帯域とスイッチ類の追加費用
TBS-h574TXは10 GbEポートが無く、SSD性能を生かすならThunderbolt直結か10 GbEアダプタ＋スイッチを追加で買う必要あり
あるよポート基素.icon
災害対策（UPS／停電時シャットダウン）
停電で書き込み中に電源断が起きるとRAIDもAPFSも壊れる恐れ。NASでもMac miniでも小型UPSをつないで自動シャットダウンを設定しておくと安全。
やってるよ基素.icon
リストア時間と費用
Backblazeは大量データをネット経由で戻すと時間がかかり、物理ディスク配送は追加料金。復旧所要日数と費用を事前に見積もると後悔しにくい。
ダウンタイムを1週間ぐらいはみておく必要がある基素.icon
HDD購入2日+ダウンロード4日+手動マージ1日
ファイルシステムの健全性チェック
QNAP（QuTS hero ZFS）ならスナップショットとスクラブでビット腐敗検知が可能。TBS-h574TXをQuTS heroで動かすか、APFS上での定期的なfsckをどう確保するかを決めておくと良い。
何もやる気がない基素.icon
オフライン／エアギャップコピー
3-2-1バックアップで「1つはオフサイト」を掲げているが、実際に月1で外付けHDDを外へ持ち出すなどの手順が未具体化
コスト削減で2-1バックアップになるんだよ基素.icon
将来拡張性
TR-004は4ベイまで。容量が天井に当たったとき、さらにDASを増やすのか、大型NASへ移行するのかロードマップを作っておくと切り替えがスムーズ。
16TBのHDD1本でとりあえず進めて将来はJBODにする？NASと違って拡張性がないからそこは難しい基素.icon
o3.icon
ハードウェア RAID モードでは「1 個だけの RAID グループ」しか作れず、RAID 5 などをあとからドライブ追加で拡張・移行できない
いま 16 TB（データ）＋2 TB（Time Machine）で空きベイ2 という構成なら、
追加の16 TBを挿しても
RAID 5/10 にオンライン追加 → 不可（全ドライブ入れ替え → フル再構築が必要）
個別ディスク/JBODモードなら「別ボリューム」として認識可。ただし 1 本目の16 TBと論理的にはつながらず、フォルダを分けて運用する形になる。
回避策
今のうちに RAID 5 (3×16 TB)＋単独 2 TBに作り直し、先行して空ベイへ dummy 16 TB（安価な低速HDDでも可）を挿しておく → 将来高容量HDDへ差し替えて reshape で拡張。
もしくは JBOD/個別で 16 TB をどんどん追加し、上位レイヤ（例: mergerFS、APFS ボリュームグループ、バックアップスクリプト）で束ねる。
バージョン管理とランサムウェア対策
NASはスナップショット＋WORM設定が可能。Mac mini案はTime Machine＋Backblazeのみなので、バージョン数や保持期間をどう組み合わせるか検討余地がある。
アクセス権と暗号化キーの管理
複数機器・クラウドに分散すると鍵管理が煩雑に。Mac mini／NASどちらを選んでも、暗号化パスフレーズ共有・保管フローを決めておくと復旧が楽。
1passwordで解決基素.icon
ノイズ・熱・電気代
オールSSDでもThunderbolt 4コントローラはそれなりに発熱。Mac mini＋HDDは常時スピンで音と消費電力が増える。常設部屋の環境条件を要確認。
複数人で作業してデータをやり取りしなければいけない場合
SLAが必要
SSD選定
エンクロージャ選定
エンクロージャーに搭載されているコントローラーが何かをチェックするのが確実。正真正銘USB4に対応するものは、ほぼASMediaの「ASM2464PD」（USB4対応）を採用しています。なんちゃって対応の方は、Intelの「JHL7440」（Thunderbolt 3対応）とUSB 3.2 Gen2対応のコントローラーを採用していることが多いです。 まず、Thunderbolt 3のコントローラーであるJHL7440とUSB3.1 Gen2のコントローラーであるJMS583が搭載されたUSB4もどきケース。
以前はこれが多かった。
これは、JHL7440だとPCIe Gen3x4だが、JMS583だとPCIeがGen3x2に制限される。
今回購入したケースは、USB4のコントローラーであるASM2464PDひとつだけを搭載した正真正銘のUSB4ケースだ。
ASM2464PDにより、PCIe Gen4x4での通信が可能となる。
Orico M2V0-C4はTomshardwareでBest USB 4 / Thunderbolt Enclosureと言われているが、上記に当てはまる
Unfortunately, not all USB 4 / Thunderbolt enclosures work properly when connected to non-Thunderbolt / USB 4 ports. When we tried plugging the Orico M234C3-U4 enclosure, another USB 4 enclosure that costs $20 less, into USB 3.2 Type-A and Type-C ports, it powered on but Windows could not actually see the SSD inside. However, the M2V0-C4 had no such problems, mounting immediately and flawlessly on two different computers over USB 3.2 Gen and USB 3.2 Gen ports.
Intel JHL7440（Thunderbolt 3コントローラー）とJMicron JMS583（USB 3.1 Gen 2 to PCIe NVMe Gen3 x2 ブリッジコントローラー）を搭載したモデル
変だな。上のブログもOricoのM2V01-C4-GYを買っていそう。仕様が変わった？
商品ページには
高性能のダブルマスタチップ制御するNVMe M.2 SSDケース
とあるから変わってなさそうだけど
同じOricoでもこっちはASM2464を明言しているし5000円も安い。全然わからない。
大量に製品を作っていて何がどういう目的で作られたのか全然わからない
発熱が激しいというレビューがあるが、箱の発熱が激しいということは放熱できているということだからいいことなのになぜマイナスをつける。SSDの温度が上がってスロットリングされてしまうという批判をしてください
外部ストレージを暗号化する
チェックサム付きシステムが何をしているかを「書き込み時」「読み込み時」「定期検査」の３段階で説明します。例として ZFS／btrfs／ReFS と、クラウド側の Google Drive を取り上げます。
書き込み時
データブロックごとにハッシュ（CRC32、SHA-256 など）を計算し、そのハッシュ値を メタデータとは別の場所 に保存する。
例：ZFS は親ブロックへポインタ＋ハッシュをまとめて記録。
二重化がある場合（RAID-Z、ミラー、Google Drive の多重コピー）は、“元ブロック” と “複製ブロック” を両方書いてハッシュもセットで格納。
読み込み時（コピーや普通のアクセス時も同じ）
1. ブロックを読み出す。
2. もう一度ハッシュを計算。
3. 保存してあったハッシュと比較。
一致 → 正常データとして上位（OS／アプリ）へ返す。
不一致 → “化けた” と判定。
予備コピーがある場合はそちらを読み直してハッシュ検証 → 正常なら自動で書き戻し（セルフヒーリング）。
予備が無い場合は即エラーを返す（データは壊れているが「壊れた」とわかる）。
→ つまりコピーを行う前に必ず検査が入るため、
「サイズも日時も同じだけど 1bit 壊れたファイル」が静かに別ディスクへ渡る確率が激減する。
定期検査（スクラブ）
“めったに読まれないブロック” は放置すると腐敗が潜伏する。
ZFS/btrfs/ReFS は月１などのスケジュールで全ブロックを強制リード → 上と同じ照合 → 壊れていれば即修復またはログ。
Google Drive などオブジェクトストレージも、データセンター側でバックグラウンド巡回を行い、壊れたコピーを別の正常コピーで置き換える。
個別システムの特徴（かんたん比較）
ZFS
32 bit CRC＋SHA-256、ミラー／RAID-Zなら即セルフヒール。
スナップショットはコピーオンライトなので古い版も同じ保護を維持。
btrfs
CRC32C。RAID1/RAID10 のときのみ自動修復、単発ドライブでは検知止まり。
ReFS（Integrity Streams）
64 KB単位でハッシュ。Storage Spaces でミラー／パリティを組むと週１で自動スクラブ。
Google Drive
オブジェクトは複数リージョン／複数マシンに保存。アップロード直後と巡回時にハッシュ検証し、壊れたコピーは自動再生成。
重要な注意
複製が１個しかない場合（ZFS シングルディスクなど）は「壊れたと判る」だけで直せない。バックアップは必須。
スクラブを止めると「読まれないまま腐る」リスクが戻ってくる。
アプリ側の論理バグ（間違ったデータを書いた）までは防げないので、世代付きバックアップと併用して “昔の正常版” を残すのが鉄則。
まとめ
チェックサム付きシステムは
1) 書き込み時にハッシュを付け、
2) 読み込みのたびに必ず照合し、
3) 定期スクラブで未使用領域も検査、
という三重構えで「サイレント腐敗を検知し、複製があれば即修復」します。
このためコピー操作そのものに特別なオプションを付けなくても、物理エラー由来の壊れたデータが別ディスクへ静かに伝搬する確率を大幅に下げられる、という仕組みです。
DAS選定
要件
ベイは最低4つ
RAIDはなくても良い
使ってない時はスリープ。使う時にはディスクアクセスしたい
市場の製品を見た感じ
OWC ThunderBay 4は信頼性が高そう
Terramasterがコスパがいい（OWCの1/3）
Macに直接接続している。RAID 1ペアの18TB HDDペアが3週間に1回Macから切断される。サポートはLEDを見ろとしか言わない。トラブルシューティングが難しい
その他のドライブは切断されない
ホストはスリープしない。
同じ問題を抱えている別のユーザーがいる。もっとも右側のベイのHDDのみに発生する。
SMART監視と通知をやってくれる
RAIDを組まなくても可能
電源周りのトラブルが多そう
o3.iconUSB と Thunderbolt で「ホスト（Mac）がスリープ／電源オフしたときに外付けケースも止まるか」の仕組みが違います。ざっくり言うと “電源ラインの扱い” と “プロトコルの通知方法” が異なるため、USB ケースでは連動が甘くなりやすい、という意味です。
物理ラインの違い
USB
5 V 給電ラインが常時生きている設計が多い
Mac がスリープしても＋5 V が残る→ブリッジ基板が動き続け、HDD も「回転停止しろ」というコマンドが来ない限り目覚めたまま
Thunderbolt
PCIe をトンネリングしたバス。ホストがスリープすると Thunderbolt リンク自体が崩れ、デバイス側コントローラもスタンバイへ
多くのケースは内部電源リレーが切れて 12 V 系統も落ちる → HDD が確実に止まる
実際、OWC ThunderBay などはシャットダウンもスリープも高い確率で追従。ただし macOS の「ハードディスクを可能ならスリープ」設定が ON だと復帰時に接続がドロップする既知バグあり プロトコル通知の違い
USB Mass Storage: SCSI START STOP UNIT／UAS Suspend などを OS が送る。しかしブリッジが未実装だと意味が無い
Thunderbolt: PCIe Power Management（ASPM）＋リンクレイヤで強制的にデバイス側電源を落とせる→ 結果として Thunderbolt の方が「Mac の電源状態をハード的に共有」しやすい
基素.icon結局Thunderboltで接続するような製品は高価なので
安いが運用が安定しない可能性があるTerraMaster製品(USB)
TerraMaster D8 Hybrid
3倍高いが運用は安定しそうでマニュアルもしっかりしているOWC製品(TB3)
ビルドクオリティやマニュアルの丁寧さはOWC 1M2で好感だった。高い分の仕事をしてる。 基素.iconこれはDASの代わりになるの？
みたいなチョイス
WoLの運用
想定構成
Mac mini
外付けDAS（最低3ベイ：SSD1＋HDD2）
DASはUSB-C/USB3でもThunderboltでも可
MBP（macOS）／Windows PC／iPad からSMBで共有フォルダへ接続
未使用時はMacもDASも静かにスリープさせる
APFS暗号化（FileVault）を有効にしても可
1. Mac miniがスリープすると、自分のIP/名前(macmini.local)をApple TVに委任
2. クライアントが smb://macmini.local にアクセス
3. Apple TVがマジックパケット(WoL)を送信
4. Mac mini起動 → ThunderboltならDAS電源も連動停止/復帰
5. 数秒〜十数秒後に共有フォルダが開く
※ Sleep Proxyがあるため、手動でWoLアプリを使う必要はない
実際にやる設定手順
【A. Mac mini】
1. システム設定 → 一般 → 共有 → ファイル共有 ON
共有フォルダを追加しユーザ権限を設定
2. システム設定 → 一般 → 省エネルギー
ネットワークアクセスでスリープ解除 ON
可能ならディスクをスリープ ON
3. ターミナル
$ sudo pmset -a sleep 30 disksleep 10 displaysleep 5 womp 1
（本体30 分でスリープ、ディスク10 分で回転停止、WoL許可）
4. IPアドレスをルーター側DHCP予約で固定
5. FileVaultはデフォルトのまま（destroyfvkeyonstandby 0）
B. Apple TV
1. 常時電源ON・同一サブネットに接続
2. 特別な設定は不要（IPv6/プライベートアドレスはデフォルトで可）
C. 外付けDAS
USBケースの場合：DASユーティリティやHDD APMで10 分程度のスピンダウンを設定
Thunderboltケースの場合：特に設定不要（Macスリープに合わせて停止）
D. クライアント側利用
MBP/iPad
Finder／Files → smb://macmini.local へ接続（数秒待てば開く）
Windows
エクスプローラ → \macmini.local\共有名（Bonjourが無ければ固定IPに変更）
トラブルシュート覚え書き
起きない→ Apple TVが省電力でLAN切断していないか／ルーターがmDNSやブロードキャストを遮断していないか確認
Windowsで名前解決失敗→ Bonjour Print Servicesを入れるか固定IPで接続
USB DASが止まらない→ DAS/HDD側アイドルタイマーを短めに再設定
SoftRAID Standard運用ならSMART自動通知が無い→ DriveDx等を常駐させる
起動設定
ある時刻だけ起動し、それ以外はスリープ
スリープ中はDASを止める
起動中はDASをスリープさせない
o3.icon
1. ターミナルでアイドルスリープを無効化
$ sudo pmset -a sleep 0 disksleep 0 womp 1
sleep 0 … 本体が放置されてもスリープしない
disksleep 0 … ディスクも回り続ける
womp 1 … Wake-on-LAN（Apple TV経由の起床）を許可
2. 毎日 23:05 にスリープ、08:00 に復帰を予約
$ sudo pmset repeat sleep MTWRFSU 23:05:00 wakeorpoweron MTWRFSU 07:55:00
sleep 行は“強制”なので idle スリープを無効にしていても必ず夜 23:05 に眠る
wakeorpoweron 行で朝 7:55 に自動復帰（DAS が回転して 8:00 に使える）
3. システム設定 → 一般 → 省エネルギー
ネットワークアクセスでスリープ解除 → オン
（Apple TV が Sleep Proxy として動作するため必須）
4. 動作確認
pmset -g sched で予約が入っているか確認
夜間に手動で pmset sleepnow してみて、朝になったら自動で起きるかテスト
FileVault はデフォルト設定のままならスリープ後も鍵が保持されるので、リモート SMB 共有はそのまま使えます。
Thunderbolt DAS は Mac が眠ると自動停止、起床で自動回転します。USB ケースの場合は DAS 側ユーティリティで「HDD 休止タイマー = 10 分」などを設定しておくと確実。
Thunderbolt（ThunderBay 4）
MacがスリープするとThunderboltリンク断＋筐体の12 Vラインが遮断→HDD確実停止。
macOS設定で｢ハードディスクを可能ならスリープ｣をOFFにしておけば、復帰時のリンク切れバグも避けられる。
USB（TerraMaster D8 Hybrid など）
USBは+5 Vが常時生きるため､コントローラが眠らずHDDが回り続ける事例がある。
D8 Hybridは｢PCのスリープに同期してHDDもスリープ｣を謳うが、フォーラムに「ベイによって止まらない」「復帰時に認識落ち」報告が残る。
回避策は①DASユーティリティでHDD休止タイマー10 分程度に設定 ②HDD APMを短くする ③pmset sleep後にディスクを強制アンマウントするスクリプトを走らせる──など運用でカバー。
pmset 設定は再起動しても保持されます（Mac OS 更新時にリセットされたら再入力）。
基素.iconHDDのスリープをミスった場合でも消費電力やHDDを考えても4万円を合理化できないんじゃないの？
o3.icon電気代で試算
– 3.5インチ NAS 用 HDD の「回転アイドル」消費：5〜6 W/台
– スタンバイ(スピンダウン) 消費：0.6〜1 W/台
– 差分 ≒ 4.5 W/台
– 夜間 23 時-翌8 時（9 h）に 3 台回り続けた場合
4.5 W ×3 台 ×9 h ≒ 0.12 kWh/日
年間 0.12 kWh ×365 日 ≒ 44 kWh
電気料金 30 円/kWh とすると約 1,300 円/年
ケースや基板の待機電力を足しても 2,000 円/年前後
HDD 寿命への影響
常時回転は軸受け摩耗の増加、ただし NAS 用ドライブは 24/7 前提 MTBF100-200 万時間
スピンダウンは発熱を下げる一方、再スピンアップ時の突入電流とヘッド着陸ストレスが増える
統計上「夜 9 時だけ止めても寿命が倍になる」ほどではない（体感差は小さい）
5年後にHDDをやめてSSDx4のraid5でいいとなる未来が来る方にかけるならTB4の方がいい
10GbEをほぼ使い切れる
SATAのSSTは8万円ぐらいするので、それで24万円
SATA SSD 4TBx4で12TB。これでもいいな
しかしRAIDを組むならQNAPのようなものにしたい
バックアップ/復旧プラン
前提
16 TBアーカイブHDDを常時オンライン
Backblazeは常時稼働（30 日以内再接続ルールを守る）
SMARTチェックは毎日実行し、しきい値超過で即通知
故障発生日を Day 0 とする
────────────────
◆ 月一手動rsyncバックアップあり
────────────────
Day –30 … ARCHIVE_2 を接続して rsync差分同期（数十分〜数時間）
Day –29〜Day –1 …
Backblaze が差分を数分〜数時間ごとにアップロード
ARCHIVE_1 で通常運用
Day 0 朝 … SMART警告／突然死
復旧フロー
1. 新HDDを「ARCHIVE_1」名で初期化（15 分）
2. ARCHIVE_2 を接続し rsync復元（満杯なら8〜10 h）
3. Backblaze で Day –29〜Day 0 の差分ZIPを生成・DL（差分が数十 GBなら1〜2 h）
この差分はどう確認する基素.icon
o3.icon“差分リスト”を自動生成してくれるわけではなく、日付フィルタで絞って自分で全部まとめて ZIP を作る手順になる。
手順（例：rsyncが前回 5/15 23:00 に完了した想定）
1. BackblazeのWebにログインし「View/Restore Files」を開く。 
2. 画面下のツリーで最上位フォルダ（コンピュータ名）をクリック。
3. フィルタ欄にある
Files uploaded from: Beginning of Backup
to: [日付選択]の「to」を 2025-05-15 23:00 にセットして Go。
→ その時点のスナップショットが表示される。 
4. 右上の「Select All」を押して ZIP 方式を選択し Restore を作成。 
差分が 30 GB 程度なら 1 時間前後で ZIP が生成され、DL できる。
5. ダウンロードした ZIP を展開し、新HDDへ上書きコピー（cp/rsync で可）。
ポイント
ツリーはディレクトリごとに展開できるが、日付フィルタを掛けて root を丸ごと選べば「散在している変更ファイル」も漏れず拾える。
4. ZIP展開→上書き（数分）
5. ARCHIVE_2 取り外し保管／Backblazeに新HDDを再登録
データ損失リスク＝「Backblaze最終送信から故障まで(数分〜数h)」のみ
────────────────
◆ 月一手動rsyncバックアップなし
────────────────
Day –∞〜Day –1 …
Backblazeのみで差分をアップロード
オフライン複製ディスクは存在しない
Day 0 朝 … SMART警告／突然死
復旧フロー
1. 新HDDを「ARCHIVE_1」名で初期化（15 分）
2. Backblaze Webで16 TB全量をZIP/USB HDD でリクエスト
・ZIP 方式: 500 GB ごとに分割 → 32 リクエスト、DL合計約2日半(下り100 Mbps想定)
・USB 送付: 8 TB単位×2台、受取まで数日＋返送手間
3. 展開して新HDDへコピー（数時間）
データ損失リスク＝「Backblaze最終送信から故障まで(数分〜数h)」は同じだが、
ダウンタイムは全量リストア完了まで丸2〜5日以上と長い
数万円の追加HDDと月一手間で、復旧時間を数日→半日に短縮できる